Hands-free transactions with a transaction confirmation request

ABSTRACT

Conducting hands-free transactions comprises a server at a payment processing system, a user computing device, and a merchant computing device. The payment processing system receives a communication from a hands-free payment application on a user device, the communication comprising a first transaction token, an identification of a user account, and a beacon identifier. The merchant may provide a challenge to the user and use the response to identify the token and account of the user. The merchant computing device can use voice patterns of the user to assist in identifying the token and account of the user. The system receives from the merchant computing device a transaction request, the transaction request comprising the first transaction token and transaction data associated with the transaction request. The system determines that the transaction is for an amount less than a configured transaction limit and communicates a request for an authorization of the transaction.

RELATED APPLICATION

This patent application claims priority under 35 U.S.C. §119 to U.S.Patent Application No. 62/023,752, filed Jul. 11, 2014 and entitled“Hands-Free Transactions with A Challenge Request.” The entire contentsof the above-identified application are hereby fully incorporated hereinby reference.

TECHNICAL FIELD

The present disclosure relates to conducting hands-free transactionswith a confirmation request, with a challenge and/or response, and witha voice recognition confirmation to allow a user to conduct transactionsthat are secure and resistant to fraud and including a transactionprocess that is more efficient for the user and a merchant system.

BACKGROUND

When consumers make purchases at a merchant location, many methods ofconducting a transaction are available. Consumers may use many differentpayment cards or accounts for purchases, such as gift cards, debitcards, credit cards, stored value cards, and other cards or accounts.The user account identifiers and other data represented by the cards maybe communicated to the merchant system via magnetic stripes, near fieldcommunication technologies, and other suitable mechanisms.

Conventional payment systems require the consumer to perform actions toprovide the user account identifiers and other data to the merchantsystem. For example, the user may be required to actuate a start buttonor initiate an application. In another example, the user may be requiredto tap or swipe a user computing device to initiate a transaction. Otheruser interactions may be required by conventional payment systems.

SUMMARY

Techniques herein provide computer-implemented methods to conducthands-free transactions. In an example embodiment, conducting hands-freetransactions comprises a server at a payment processing system, a usercomputing device, and a merchant computing device. The paymentprocessing system receives a communication from a hands-free paymentapplication on a user computing device, the communication comprising afirst transaction token, an identification of a user account, and abeacon identifier received from a merchant computing device associatedwith the merchant system by the user computing device. The systemreceives from the merchant computing device a transaction request, thetransaction request comprising the first transaction token andtransaction data associated with the transaction request. The systemdetermines that the transaction is for an amount greater than aconfigured transaction limit and communicates a request for anauthorization of the transaction. The system receives the authorizationof the transaction and conducts the transaction between the user accountand the merchant system.

In another example embodiment, the payment processing system receives acommunication from a hands-free payment application on a user device,the communication comprising a first transaction token, anidentification of a user account, and a beacon identifier. The merchantmay provide a challenge to the user and use the response to identify thetoken and account of the user. The system receives, from the merchantcomputing device a transaction request, the transaction requestcomprising the first transaction token identified with the challengeresponse and transaction data associated with the transaction request.The system conducts the transaction between the user account and themerchant system.

In another example embodiment, a merchant computing device receives aplurality of transaction tokens from a plurality of user computingdevices associated with a plurality of user accounts, the user computingdevices having received a beacon from the merchant system computingdevice. The merchant computing device identifies a product for purchasefrom a particular user and issues a challenge to the user. The merchantcomputing device receives an input voice response of the user andidentifies a voice pattern of the user. The merchant computing deviceidentifies a user account associated with the voice pattern andcommunicates to a payment processing system a transaction requestassociated with the particular user account.

In certain other example aspects described herein, systems and computerprogram products to conduct hands-free transactions are provided.

These and other aspects, objects, features, and advantages of theexample embodiments will become apparent to those having ordinary skillin the art upon consideration of the following detailed description ofillustrated example embodiments.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram depicting a system for conducting hands-freetransactions with challenge request, in accordance with certain exampleembodiments.

FIG. 2 is a block flow diagram depicting a method for conductinghands-free transactions, in accordance with certain example embodiments.

FIG. 3 is a block flow diagram depicting a method for a merchant deviceto broadcast a beacon via a wireless communication, in accordance withcertain example embodiments.

FIG. 4 is a block flow diagram depicting a method for a user computingdevice to recognize a merchant computing device beacon, in accordancewith certain example embodiments.

FIG. 5 is a block flow diagram depicting a method for a merchant deviceto identify a user and transmit transaction request to paymentprocessing system, in accordance with certain example embodiments.

FIG. 6 is a block flow diagram depicting a method for a merchant deviceto identify a user and transmit transaction request to paymentprocessing system based on voice patterns of a user, in accordance withcertain example embodiments.

FIG. 7 is a block flow diagram depicting a method for conductinghands-free transactions with a confirmation, in accordance with certainexample embodiments.

FIG. 8 is a block flow diagram depicting a method for a paymentprocessing system to request a confirmation of a transaction from a userdevice, in accordance with certain example embodiments.

FIG. 9 is a block diagram depicting a computing machine and module, inaccordance with certain example embodiments.

DETAILED DESCRIPTION OF EXAMPLE EMBODIMENTS Overview

The example embodiments described herein provide computer-implementedtechniques to conduct hands-free payments. In an example embodiment, auser installs a hands-free application on a user computing device. Theuser maintains a user account on a payment processing system forconducting transactions. A merchant computing device at a merchantlocation provides a beacon identifier that is received by the usercomputing device.

The user computing device generates a token for conducting a transactionand transmits the token to the payment processing system. Upon averification, the payment processing system transmits the token to themerchant computing device. The merchant computing device stores thetoken for use in a transaction with the user computing device.

The user approaches the salesperson to conduct a transaction using thehands-free application. The salesperson initiates the transaction on themerchant computing device and offers a challenge to the user foridentification of the user account. In an example, the salesperson asksfor the initials of the user. The salesperson inputs the response to thechallenge in the merchant computing device. One or more user accountsare displayed to the salesperson for selection based on the input of theresponse. In an example, a picture and a name of each of the one or moreusers is displayed. The salesperson identifies the user account on auser interface of the merchant computing device from the one or moreusers displayed.

The merchant computing device transmits the transaction details and thetoken for the user account to the payment processing system. The paymentprocessing system verifies the details of the transaction and the token,and conducts the transaction. The payment processing system maycommunicate a notification to the user computing device with thetransaction data.

In another example embodiment, when the payment processing systemreceives the transaction details and the token for the user account fromthe merchant device, the payment processing system is restricted fromconducting the transaction by a configured setting in the user accountor in the token. For example, the user account has a configured limit of$50 for hands-free transactions without a user authorization. If theamount of the pending transaction is over $50, the payment processingsystem transmits an authorization request to the user computing devicefor the transaction.

The user device displays a request to the user to input an authorizationor a refusal of the transaction. Upon receiving an input of anacceptance, the user computing device creates a second token comprisingthe authorization of the transaction. The second token is transmitted tothe payment processing system. The payment processing system conductsthe transaction using the second token.

In certain example embodiments, instead of a challenge and response, themerchant computing device may use voice recognition software to identifythe user. For example, the salesperson may ask the user a question andthe merchant computing device receives the audible response. Themerchant computing device compares the voice pattern of the user to adatabase of voice patterns and identifies the user.

If a strong match exists for any of the stored voice patterns, thehands-free payment application retrieves the user account associatedwith the matching speaker identification model and conducts thetransaction with the user account.

In another example embodiment, the merchant computing device may capturea picture of the user using a camera module on the merchant computingdevice. The merchant computing device may match the picture against alocal database of pictures. The matching of the pictures may take placeon the merchant computing device, at the payment processing system, ofin any suitable location. In an example, the merchant computing devicemay access a database of images and match the image of the that has beencaptured by the merchant computing device. Upon locating a match, themerchant computing device may verify that the user matches the useraccount being utilized for the transaction. In another example, themerchant computing device may receive an image from the paymentprocessing system or other location in advance of the consumerapproaching the merchant terminal device. For example, the image may beobtained at the time that the consumer enters the store.

In another example embodiment, the challenges are presented based onrisk signals derived from features such as (1) user's risk profile (2)the risk tolerance of merchant and (3) number of users who have checkedin to the store. For example, for a low value transaction, the merchantcomputing device may utilize a simple challenge, but a more complexchallenge for a high value transaction. In another example, if only oneuser is at the location of the merchant, then a complex challenge maynot be needed to identify the user.

By using and relying on the methods and systems described herein, thehands-free application and payment processing system dynamically provideaccurate, efficient, secure, and reliable transactions for a user. Assuch, the systems and methods described herein may be employed to allowthe user to conduct a transaction using communications from the usercomputing device, the merchant computing device, and the paymentprocessing system that are secure and efficient. The user is allowed toconduct hands-free transactions with a confirmation request to allow theuser to conduct transactions that are secure and resistant to fraud. Theuser is allowed to conduct hands-free transactions with a challenge andresponse to conduct transactions that are secure, efficient, andresistant to fraud. The user is allowed to conduct hands-freetransactions with a voice recognition confirmation to conducttransactions that are secure, efficient, and resistant to fraud. Thesystem may use communication between the user computing device and thepayment processing system to reduce fraudulent activities by themerchant. Hence, the methods and systems described herein decrease userfrustration and permit accurate, secure, efficient, and reliabletransactions for a user.

Example System Architectures

Turning now to the drawings, in which like numerals indicate like (butnot necessarily identical) elements throughout the figures, exampleembodiments are described in detail.

FIG. 1 is a block diagram depicting a system 100 for conductinghands-free transactions, in accordance with certain example embodiments.As depicted in FIG. 1, the system 100 includes network computing devices110, 130, 140, and 150 that are configured to communicate with oneanother via one or more networks 120. In some embodiments, a user 101 ora salesperson 102 associated with a device must install an applicationand/or make a feature selection to obtain the benefits of the techniquesdescribed herein.

In example embodiments, the network 120 can include a local area network(“LAN”), a wide area network (“WAN”), an intranet, an Internet, storagearea network (“SAN”), personal area network (“PAN”), a metropolitan areanetwork (“MAN”), a wireless local area network (“WLAN”), a virtualprivate network (“VPN”), a cellular or other mobile communicationnetwork, Bluetooth, Bluetooth low energy, near field communication(“NFC”), Wi-Fi, or any combination thereof or any other appropriatearchitecture or system that facilitates the communication of signals,data, and/or messages. Throughout the discussion of example embodiments,it should be understood that the terms “data” and “information” are usedinterchangeably herein to refer to text, images, audio, video, or anyother form of information that can exist in a computer-basedenvironment.

Each network computing system 110, 130, 140, and 150 includes a devicehaving a communication module capable of transmitting and receiving dataover the network 120. For example, each network computing device 110,130, 140, and 150 can include a server, desktop computer, laptopcomputer, tablet computer, a television with one or more processorsembedded therein and/or coupled thereto, smart phone, handheld computer,personal digital assistant (“PDA”), or any other wired or wireless,processor-driven device. In the example embodiment depicted in FIG. 1,the network computing devices 110, 130, 140, and 150 are operated byusers 101, merchant system operators, payment processing systemoperators, and salespersons 102, respectively.

In the examples provided herein, actions performed by the user 101 maybe performed by the salesperson 102 in other embodiments. Examplesdescribed as being performed by the user computing device 110 may beperformed by the merchant computing device 150 or the payment processingsystem 140 in other embodiments.

An example user computing device 110 comprises a data storage unit 112,a communication application 113, a web browser 114, a user interface115, a global positioning system (“GPS”) module 118, and a hands-freepayment application 116.

In an example embodiment, the data storage unit 112 comprises a local orremote data storage structure accessible to the user computing device110 suitable for storing information. In an example embodiment, the datastorage unit 112 stores encrypted information, such as HTML5 localstorage.

In an example embodiment, the user 101 uses a communication application113, such as a web browser 114 application or a stand-alone hands-freepayment application 116, to view, download, upload, or otherwise accessdocuments or web pages via a distributed network 120.

In an example embodiment, the communication application 113 can interactwith web servers or other computing devices connected to the network120, including the user computing device 110, a point of sale (“POS”)terminal 134 associated with a merchant system 130 and/or a web server(not depicted) associated with a payment processing system 140.

In an example embodiment, the web browser 114 can enable the user 101 tointeract with web pages using the user computing device 110.

In an example embodiment, the user interface 115 enables the user 101 tointeract with the hands-free payment application 116 and/or web browser114. For example, the user interface 115 may be a touch screen, avoice-based interface, or any other interface that allows the user 101to provide input and receive output from an application or module on theuser computing device 110. In an example embodiment, the user 101interacts via the user interface 115 with the hands-free paymentapplication 116 and/or web browser 114 to configure user accounts on apayment processing system hands-free module 141. In another exampleembodiment, the user 101 interacts via the user interface 115 with thehands-free payment application 116 and/or the web browser 114 to enablehands-free payments, if needed.

In an example embodiment, the GPS module 118 communicates with one ormore satellites of the Global Positioning System (“GPS”) or othersatellite-based location system to determine the location of the usercomputing device 110. In an example embodiment, the delivery system 140periodically or continuously communicates with the GPS module 118 duringapplicable time periods to determine and log the location of the usercomputing device 110. In another embodiment, the location of the usercomputing device 110 is identified based on Wi-Fi signals, cellularlocation, or any suitable location identifying technology. Any locationdetermining hardware, software, or combination of hardware and softwareis represented by the GPS module 118.

In an example embodiment, the hands-free payment application 116 is aprogram, function, routine, applet, or similar entity that exists on andperforms its operations on the user computing device 110. In certainexample embodiments, the user 101 must install the hands-free paymentapplication 116 and/or make a feature selection on the user computingdevice 110 to obtain the benefits of the techniques described herein. Inan example embodiment, the user 101 may access the hands-free paymentapplication 116 on the user computing device 110 via the user interface115. In an example embodiment, the hands-free payment application 116may be associated with the payment processing system 140. In anotherexample embodiment, the application may be associated with the merchantsystem 130. In yet another example embodiment, two hands-free paymentapplications 116 exist, one associated with the merchant system 130 andanother associated with the payment processing system 140.

In certain example embodiments, one or more functions herein describedas performed by the hands-free payment application 116 may also beperformed by a web browser 114 application, for example, a web browser114 application associated with a merchant system website 134 orassociated with the payment processing system 140. In certain exampleembodiments, one or more functions herein described as performed by thehands-free payment application 116 may also be performed by the usercomputing device operating system. In certain example embodiments, oneor more functions herein described as performed via the web browser 114may also be performed via the hands-free payment application 116.

In an example embodiment, the user computing device 110 communicateswith the merchant system 130 and the payment processing system 140 viathe network 120.

An example merchant system 130 comprises a server 133, POS terminal 134,and a data storage unit 132. In an example embodiment, the merchantsystem 130 communicates with a payment processing system 140 over thenetwork 120. In example embodiments described herein, the merchantsystem 130 is a separate entity from the payment processing system 140.However, in certain other example embodiments, the merchant system 130is associated with a payment processing system 140, is a component ofanother system along with a payment processing system 140, comprises apayment processing system 140, or is a component of a payment processingsystem 140.

In an example embodiment, the data storage unit 132 comprises a local orremote data storage structure accessible to the merchant system 130suitable for storing information. In an example embodiment, the datastorage unit 132 stores encrypted information, such as HTML5 localstorage.

In an example embodiment, the web server 133 provides content accessibleby the user 101 through the web browser 114 and/or hands-free paymentapplication 116 on the user computing device 110, including but notlimited to html documents, images, style sheets, and scripts. In anexample embodiment, the server 133 supports the merchant system website134.

In an example embodiment, the POS terminal 134 comprises a computingdevice that is configured to accept payments from users 101, from usercomputing devices 110, or other parties. The POS terminal 134 maycommunicate, via the network, with the user computing device 110, themerchant server 133, the merchant computing device 150, the paymentprocessing system 140, or any suitable device or system. The POSterminal 134 may comprise a barcode scanner, a user interface, acustomer display, or any suitable elements to enable the salesperson 102to initiate and conduct a transaction. The POS terminal 134 in theexample embodiments may comprise a function enabling the salesperson 102to input an indication that the transaction was conducted with thehands-free application 156 on the merchant computing device 150, andthat the POS terminal 134 should consider the transaction completed.

An example payment processing system 140 comprises a payment processingsystem hands-free module 141 and a data storage unit 142. In an exampleembodiment, the user 101 has a user account with the payment processingsystem 140. In an example embodiment, the payment processing systemhands-free module 141 manages the user account. For example, the paymentprocessing system hands-free module 141 may receive a user's usernameand password and allow the user 101 to access services provided by thepayment processing system 140. In an example embodiment, the paymentprocessing system hands-free module 141 communicates with the hands-freepayment application 116 resident on the user computing device 110. Inanother example embodiment, the payment processing system hands-freemodule 141 communicates with the user 101 via the user computing deviceweb browser 114. In an example embodiment, the payment processing systemhands-free module 141 manages the user's digital wallet account.

In an example embodiment, the payment processing system hands-freemodule 141 communicates with the merchant system 130, account issuersystems (not depicted) and/or acquirers (not depicted), or othersuitable financial systems (not depicted) to process payments. In anexample embodiment, the payment processing system hands-free module 141retrieves user financial account information and credit accountinformation from other financial institutions, from the data storageunit 142, or by communicating with the hands-free payment application116 over the network 120. In an example embodiment, the paymentprocessing system hands-free module 141 requests a credit authorizationfrom an issuer system through an acquirer system and receives the creditauthorization. In an example embodiment, the payment processing systemhands-free module 141 initiates a bank transfer with a financialinstitution system. In an example embodiment, the payment processingsystem hands-free module 141 receives the bank transfer or completes acredit card transaction associated with the credit card authorization.

In certain example embodiments, the payment processing system hands-freemodule 141 creates tokens, verifies tokens, verifies rescue codes, andperforms other actions as described herein. In an example embodiment,the payment processing system hands-free module 141 generates a receiptof a transaction and transmits the receipt to the user computing device110.

In an example embodiment, the data storage unit 142 comprises any localor remote data storage structure accessible to the payment processingsystem hands-free module 141 suitable for storing information. In anexample embodiment, the data storage unit 142 stores encryptedinformation, such as HTML5 local storage. In an example embodiment, thedata storage unit 142 stores user financial account information and/oruser credit account information.

An example merchant computing device 150 comprises a data storage unit152, a communication application 153, a web browser 154, a userinterface 155, and a hands-free payment application 156.

In an example embodiment, the data storage unit 152 comprises a local orremote data storage structure accessible to the merchant computingdevice 150 suitable for storing information. In an example embodiment,the data storage unit 152 stores encrypted information, such as HTML5local storage.

In an example embodiment, the salesperson 102 uses a communicationapplication 153, such as a web browser 154 application or a stand-alonehands-free payment application 116, to view, download, upload, orotherwise access documents or web pages via a distributed network 120.

In an example embodiment, the communication application 153 can interactwith web servers or other computing devices connected to the network120, including the merchant POS terminal 134, a web server 133associated with a merchant system 130 and/or a payment processing systemhands-free module 141.

In an example embodiment, the web browser 154 can enable the salesperson102 to interact with web pages using the merchant computing device 150.In an example embodiment, the salesperson 102 is able to accesstransaction information form the POS terminal 134, and access useraccount information from the user computing device 110 and/or thepayment processing system hands-free module 141.

In an example embodiment, the user interface 155 enables the salesperson102 to interact with the hands-free payment application 156 and/or webbrowser 154. For example, the user interface 155 may be a touch screen,a voice-based interface or any other interface that allows thesalesperson 102 to provide input and receive output from an applicationor module on the merchant computing device 150. In an exampleembodiment, the salesperson 102 interacts via the user interface 155with the hands-free payment application 156 and/or web browser 154 toaccess a user token to conduct a transaction via the payment processingsystem 140.

In an example embodiment, the hands-free payment application 156 is aprogram, function, routine, applet, or similar entity that exists on andperforms operations on the merchant computing device 150. In certainexample embodiments, the salesperson 102 must install the hands-freepayment application 156 and/or make a feature selection on the merchantcomputing device 150 to obtain the benefits of the techniques describedherein. In an example embodiment, the salesperson 102 may access thehands-free payment application 156 on the merchant computing device 150via the user interface 155. In an example embodiment, the hands-freepayment application 156 may be associated with the merchant system 130.In another example embodiment, the application may be associated withthe payment processing system 140. In yet another example embodiment,there are two applications 156, one associated with the merchant system130 and another associated with the payment processing system 140.

In certain example embodiments, one or more functions herein describedas performed by the hands-free payment application 156 may also beperformed by a web browser 154 application, for example, a web browser154 application associated with a merchant system website 134 orassociated with the payment processing system 140. In certain exampleembodiments, one or more functions herein described as performed by thehands-free payment application 156 may also be performed by the merchantcomputing device operating system. In certain example embodiments, oneor more functions herein described as performed via the web browser 154may also be performed via the hands-free payment application 156.

In certain alternate example embodiments, the merchant computing device150 may be part of the merchant system 130. The merchant computingdevice 150 functions described herein may be performed by the merchantserver 133, POS terminal 134, or other merchant device.

It will be appreciated that the network connections shown are exampleand other means of establishing a communications link between thecomputers and devices can be used. Moreover, those having ordinary skillin the art having the benefit of the present disclosure will appreciatethat the user computing device 110, the merchant system 130, the POSterminal 134, the payment processing system 140, and the merchantcomputing device 150 illustrated in FIG. 1 can have any of several othersuitable computer system configurations. For example, a user computingdevice 110 embodied as a mobile phone or handheld computer may or maynot include all the components described above.

In example embodiments, the network computing devices and any othercomputing machines associated with the technology presented herein maybe any type of computing machine such as, but not limited to, thosediscussed in more detail with respect to FIG. 9. Furthermore, anymodules associated with any of these computing machines, such as modulesdescribed herein or any other modules (scripts, web content, software,firmware, or hardware) associated with the technology presented hereinmay by any of the modules discussed in more detail with respect to FIG.9. The computing machines discussed herein may communicate with oneanother as well as other computer machines or communication systems overone or more networks, such as network 120. The network 120 may includeany type of data or communications network, including any of the networktechnology discussed with respect to FIG. 9.

Example Processes

The example methods illustrated in FIGS. 2-8 are described hereinafterwith respect to the components of the example operating environment 100.The example methods of FIGS. 2-8 may also be performed with othersystems and in other environments.

FIG. 2 is a block diagram depicting a method 200 for conducting ahands-free transaction, in accordance with certain example embodiments.The method 200 is described with reference to the components illustratedin FIG. 1.

In block 210, the merchant computing device 150 broadcasts a beacon viaa wireless communication. Block 210 is described in greater detailhereinafter with reference to the method 210 described in FIG. 3.

FIG. 3 is a block diagram depicting a method 210 for a merchantcomputing device 150 to broadcast a beacon via a wireless communication,in accordance with certain example embodiments. The method 210 isdescribed with reference to the components illustrated in FIG. 1.

In block 310, the merchant system 130 registers with the paymentprocessing system 140. For example, the merchant system 130 may contactthe payment processing system 140 to become associated with thehands-free transaction process. The merchant system 130 may obtain amerchant account, receive the appropriate applications and software,request authorization to participate, or perform any action required bythe payment processing system 140.

The merchant system 130 may use the merchant computing device 150, thepoint of sale (“POS”) terminal 134, the merchant server 133, or anysuitable computing device to request and configure a merchant account.The merchant account may allow the merchant system 130 to participate insome or all of the activities described in the methods herein.

In block 320, the merchant computing device 150 installs a hands-freepayment application 156. In an example, the merchant computing device150 is registered as an authorized agent of the merchant system 130. Themerchant computing device 150 may be identified by an alphanumericidentifier, by a provided password, a serial number, or by any suitablemanner.

In an example, the merchant computing device 150 downloads thehands-free payment application 156 from the payment processing systemhands-free module 141 over the network 120. The merchant computingdevice 150 may download the hands-free payment application 156 from themerchant system server 133. The merchant computing device 150 may obtainthe hands-free payment application 156 from any suitable location. Thehands-free payment application 156 on the merchant computing device 150may be integrated into an existing account that is shared with themerchant system server 133, the POS terminal 134, or any suitablecomputing device or system. A salesperson 102 or another merchant systemoperator may be required to make a feature selection to obtain thebenefits of the techniques described herein.

In block 330, the merchant computing device 150 receives a beaconidentifier. For example, the hands-free payment application 156, themerchant computing device 150, the merchant system server 133, oranother computing device requests a beacon identifier from the paymentprocessing system 140. The beacon may be any wireless signal emitted bythe merchant computing device 150 comprising a beacon identifier, amerchant system 130 identifier, a merchant computing device 150identifier, or other identifier.

In an example, the beacon identifier is a service set identifier(“SSID”), or other network name or identifier. The beacon identifier maybe generated by the payment processing system hands-free module 141, themerchant computing device 150, the merchant server 133, or any suitablecomputing device. In certain embodiments, the beacon identifier is aunique, but fixed, identifier. That is, a particular beacon identifiermay be utilized until changed by the payment processing systemhands-free module 141, the merchant computing device 150, the merchantserver 133, or any suitable computing device. In an alternateembodiment, the beacon identifier may be unique, but random. That is,the beacon identifier may be changed randomly, or upon any suitableschedule by the payment processing system hands-free module 141, themerchant computing device 150, the merchant server 133, or any suitablecomputing device.

The wireless signal emitted by the merchant computing device 150 may beany suitable technology, such as Wi-Fi direct, Bluetooth, low-energyBluetooth, infrared, or any other suitable technology, and the merchantcomputing device 150 may include corresponding hardware and softwarecomponents to emit the beacon via the associated technology.

In block 340, the merchant computing device 150 transmits the beacon viawireless communication at the location of the merchant system 150. Themerchant computing device 150 may be configured to broadcast thewireless signal at only certain times or locations, or continuously. Themerchant computing device 150 may limit or extend the strength of thebroadcast beacon, if needed. The beacon is receivable and recognizableby other computing devices that are within range of the wireless signal.The beacon may be transmitted on a single communication technology or ona plurality of communication technologies.

In a certain example embodiment, the beacon identifier is programmed onexternal communication access points. The merchant hands-freeapplication 156 may be used to configure the external communicationaccess point(s). For example, the merchant hands-free application 156may utilize functions of the merchant computing device 150 tocommunicate instructions to the external communication access points.The instructions may include the beacon identifier, the requestedcommunication technology, the time to broadcast, and/or any othersuitable instructions. The instructions may be provided by any othersuitable computing device.

The external communication access points may be employed to allow avariety of user computing devices 110 to receive the beacon despitediffering wireless communication technology capabilities or in variouslocations in the merchant location. The external communication accesspoints may allow the beacon to be broadcast over a wider area than themerchant computing device 150 alone is capable of broadcasting.

From block 340, the method 210 proceeds to block 220 of FIG. 2.

Returning to FIG. 2, in block 220, the user computing device 110recognizes the merchant computing device beacon. Block 220 is describedin more detail hereinafter with reference to the method 220 described inFIG. 4.

FIG. 4 is a block diagram depicting a method 220 for the user computingdevice 110 to recognize the merchant computing device beacon, inaccordance with certain example embodiments. The method 220 is describedwith reference to the components illustrated in FIG. 1.

In block 410, the user 101 registers with the payment processing system140. For example, the user 101 may contact the payment processing system140 to register a user account. The user 101 may obtain a user accountnumber, receive the appropriate applications and software to install onthe user computing device 110, request authorization to participate inthe hands-free payment processing, or perform any action required by thepayment processing system 140. The user 101 may utilize the functions ofthe user computing device 110, such as the user interface 115 and theweb browser 114, to register and configure a user account.

In block 420, the user computing device 140 installs a hands-freepayment application 116. For example, the user computing device 110downloads the hands-free payment application 116 from the paymentprocessing system hands-free module 141 over the network 120. The usercomputing device 110 may obtain the hands-free payment application 116from any other suitable location. The hands-free payment application 116on the user computing device 110 may be configured with the user accountinformation, user preferences, or other suitable information. A user 101may be required to make a feature selection to obtain the benefits ofthe techniques described herein.

The hands-free payment application 116 may provide options, data,configurable alerts, and other suitable features to the user 101. Forexample, the hands-free payment application 116 may comprise a listingof participating merchant systems 130 and merchant locations. Thelisting may be updated periodically from the payment processing system140. The hands-free payment application 116 may notify the user 101 whenthe user 101 is within a configured vicinity of a participating merchantsystem 130. The hands-free payment application 116 may provide the user102 with options to update payment preferences. The hands-free paymentapplication 116 may provide the user 101 with a listing of recenttransactions. The hands-free payment application 116 may provide anyother suitable information to the user 101.

In block 430, the user computing device 110 enters a location of themerchant system 130. The user 101 may enter the merchant locationcarrying the user computing device 101 in a pocket or a bag, in thehands of the user 101, or in any suitable manner. The location of themerchant system 130 may be a store location, a kiosk location, or anysuitable physical location of a merchant system 130. In an alternateexample, a salesperson 102 may be mobile and arrive at a location of theuser 101. For example, the merchant system 130 may be a restaurant andthe salesperson 102 may be a delivery person possessing a merchantcomputing device 150.

In certain example embodiments, the hands-free payment application 116alerts the user 101 when the user 101 is in the vicinity of a merchantsystem 130 that accepts hands-free payments. The alert may be providedvia a message on the user computing device 110, via an email or a text,or in any suitable manner.

The alert may be based on the location of the user 101 as determined bythe GPS module 118. For example, the hands-free payment application 116accesses the GPS data from the GPS module 118 and compare the GPSlocation to a list of locations of merchant systems 130 that accepthands-free payments. If a match results from the comparison, then analert is generated and provided to the user. The match may result if theuser 101 is within a configured distance of the merchant system 130.

The alerts may be configured to alert in any suitable manner. In anexample, the alerts may be combined in commercially dense environmentsor the alerts may be presented individually. In another example, thealerts may be configured to only alert the user 101 a configured numberof times. For example, the alert may be presented three times, but upona fourth instance, the alert is not presented. The alerts may bepresented as a notification with an audible alert, a vibration, a popupalert on the user interface 115 of the user computing device 110, orother suitable alert.

In block 440, the user computing device 110 recognizes a beacon viawireless communication at the location of the merchant system 130 andapproves the merchant system 130. The user computing device 110 may beconfigured to search for beacons or other wireless signals. Uponentering the range of the signal of the merchant computing device 130,the user computing device 110 receives the beacon. The user computingdevice 110 interprets the data transmitted in the beacon and recognizesthat the beacon is associated with the payment processing system 140 andthe hands-free payment application 116. The user computing device 110may compare the data from the beacon to a database of beacon data todetermine an identity of the merchant system 130 associated with thebeacon and/or to verify the authenticity of the beacon.

The hands-free payment application 116 interprets the data that isprovided in the beacon. For example, the hands-free payment application116 extracts data from the beacon, such as a beacon identifier, amerchant system name, communication technology requirements, or anyother suitable information.

From block 440, the method 220 returns to block 230 of FIG. 2.

Returning to FIG. 2, in block 230, the user computing device 110generates a token for a potential transaction. The token may be any dataassociated with the user account that is generated by the user computingdevice 110 for secure transmission to another computing device. Thetoken may represent an authorization or acknowledgement by the usercomputing device 110 that the user computing device 110 is incommunication with a merchant computing device 110 and that atransaction may be forthcoming. The token may comprise a user accountidentifier, the beacon identifier, a user computing device 110identifier, or any suitable data. The token may be encrypted orotherwise configured to only be readable by one or more of the paymentprocessing system hands-free module 141, the user computing device 110,a financial account server associated with the payment processing system140, or any suitable computing system. In certain example embodimentsherein, the token, or certain portions of the token, is not readable bythe merchant computing device 150. To generate the token, the usercomputing device 110 may compile all of the data needed for the tokeninto a data file and insert identifiers, labels, or other items toprepare the token for transmission. The token may be generated inresponse to receiving the beacon from the merchant computing device 150.That is, the token is not generated until the user computing device 110recognizes the beacon and recognizes a need to transmit the token basedon the identify of the merchant system 130, the location of the usercomputing device 110, or any other factors. In an alternate embodiment,the token is created in advance. The token, or a series of tokens, maybe created and stored on the data storage unit 112 of the user computingdevice 110. The token may be accessed from the storage location andutilized when requested by the hands-free payment application 116.

The token may provide a time that the token will expire. For example,the token may only be usable for one hour after being generated. In theexample, after one hour has elapsed, the token is no longer valid foruse and the payment processing system 140 will reject any transactionrequest including an expired token. In certain example embodiments, thetoken comprises the beacon identifier, the location of the usercomputing device 110, the user account identifier, or any other suitabledata.

The token may be generated by the hands-free application 116, or anotherfunction of the user computing device 110. For example, an applicationoperating on a secure element of the user computing device 110 maygenerate the token.

In certain embodiments, a token is not generated by the user computingdevice 110. For example, the payment processing system 140 may generatethe token. The payment processing system 140 may receive, from the usercomputing device 110, a set of authentication data for the user accountand generate a token. The authentication data may comprise user 101data, account data, passwords, user computing device 110 data, or anysuitable data that may be used to authenticate the user account. Theauthentication data may be transmitted to the payment processing system140 when the user computing device 110 receives the beacon from themerchant computing device 150. The user computing device 110 may accessthe authentication data from a database on the data storage unit 112, orfrom data stored in the hands-free payment application 116. Theauthentication data is transmitted in a similar fashion as thedescription of the transmission of the token from the user computingdevice 110 to the payment processing system 140. The token that isgenerated by the payment processing system 140 is transmitted back tothe user computing device 110 or to the merchant computing device 150 onbehalf of the user computing device 110.

In block 240, the user computing device 110 transmits the token to thepayment processing system hands-free module 141. The user computingdevice 110 may transmit a new token at the time that the user computingdevice 110 recognizes the beacon and the beacon identifier, at a timethat a previous token has expired, or upon any suitable schedule. Theuser computing device 110 may transmit the token via an Internetcommunication over the network 120, Bluetooth communication, Wi-Ficommunication, cellular connection, or via any suitable communicationprotocol.

The payment processing system hands-free module 141 approves the tokenand transaction parameters. The payment processing system hands-freemodule 141 receives the token and any associated information from theuser computing device 110 and determines if the beacon identifier can beverified.

For example, the payment processing system hands-free module 141 maycompare the beacon identifier to a database to determine if the beaconidentifier is registered and approved. The payment processing systemhands-free module 141 may compare a location of the user computingdevice 110, as determined by the global positioning system (“GPS”)module 118, to a database of locations associated with the beaconidentifiers. If not provided already, the payment processing systemhands-free module 141 may request the GPS location of the user computingdevice 110 in a communication over the network 120 and receive aresponse from the user computing device 110. If the location of the usercomputing device 110 matches the expected location of the merchantcomputing device 150, then the token is verified. Any other suitablecriteria for verifying the token may be employed.

The payment processing system hands-free module 141 may verify the useraccount on the payment processing system 140 to determine if the useraccount is active and available for transactions. For example, thepayment processing system may access the user account and determine ifthe account has funds available for use as stored value funds, or if theaccount has a valid credit or debit account associated with the accountwith which to conduct transaction.

In block 250, the payment processing system hands-free module 141transmits the token to a merchant computing device 150. If the token isverified, the payment processing system hands-free module 141communicates the token to the merchant computing device 150 to allow ahand-free transaction to be conducted. The token provides the merchantcomputing device 150 with the authorization to initiate a transaction onbehalf of the user account.

In an alternate embodiment, the user computing device 110 provides thetoken directly to the merchant computing device 150. For example, theuser computing device 110 generates the token as described in block 230and transmits the token to the merchant computing device 150 instead ofto the payment processing system 140. In a certain embodiment, the usercomputing device 110 may require approval from the payment processingdevice 140 before transmitting the token to the merchant computingdevice 150.

Alternatively, the user computing device 110 may transmit authorizationdata to the payment processing system. The authentication data maycomprise user 101 data, account data, passwords, user computing device110 data, or any suitable data that may be used to authenticate the useraccount. The authentication data may be transmitted to the paymentprocessing system 140 when the user computing device 110 receives thebeacon from the merchant computing device 150. The user computing device110 may access the authentication data from a database on the datastorage unit 112, or from data stored in the hands-free paymentapplication 116. The authentication data is transmitted in a similarfashion as the description of the transmission of the token from theuser computing device 110 to the payment processing system 140. Thetoken is generated by the payment processing system 140 and istransmitted back to the user computing device 110. The user computingdevice 110 then transmits the received token to the merchant computingdevice 150.

In block 260, the salesperson 102 enters transaction details into themerchant computing device 150. In an example, the user 101 selects aproduct for purchase at the location of the merchant system 130. Theterm “product” includes tangible and intangible products, as well asservices. The salesperson 102 scans the product with a barcode scanneror in any suitable manner enters the product details into the merchantcomputing device 150. The transaction data may include the productidentification, the product price, or any other suitable information.

In block 270, the merchant computing device 150 identifies the user 101and transmits a transaction request to the payment processing system140. Block 270 is described in more detail hereinafter with reference tothe method 270 a as described in FIG. 5 and the method 270 b asdescribed in FIG. 6.

FIG. 5 is a block diagram depicting a method 270 a for the merchantcomputing device 150 to identify the user 101 and to transmit thetransaction request to the payment processing system 140. The method 270a is described with reference to the components illustrated in FIG. 1.

In block 510, the salesperson 102 issues a challenge to the user 101. Inan example, the salesperson 102 asks the user 101 for the initials ofthe user 101. In another example, the salesperson 102 asks the user 101for the last four digits of the phone number of the user 101. In anotherexample, the salesperson 102 asks the user 101 for a configuredpassword. Any suitable challenge may be issued by the salesperson 102.In an example embodiment, the response to the challenge does not provideany secure or private information.

In block 520, the user 101 provides the challenge response to thesalesperson 102. As described in the example challenges, the responsesmay be the initials of the user 101, the last four digits of the phonenumber of the user 101, or a configured password. Any configuredchallenge response may be utilized. In certain embodiments, the responsemay be a spoken response, a hand gesture, a keypad entry, a display ofan identification card, or any suitable response.

In block 530, the salesperson 102 inputs the challenge response of theuser 101. In an example, if the user 101 indicates that the initials ofthe user 101 are “AC,” then the salesperson 102 inputs “AC” into thehands-free payment application 156 of the merchant computing device 150.In an example, the user interface 115 of the hands-free paymentapplication 156 or the merchant computing device 150 displays a requestfor an entry of the response of the user 101. The salesperson 102 entersthe response via a virtual or physical keyboard, voice dictation, or inany suitable manner. In an alternate example, the user 101 enters theresponse into the user interface 115 of the hands-free paymentapplication 156 or the merchant computing device 150

In block 540, the merchant computing device 150 displays potential usersbased on the challenge response. A list of users 101 that are associatedwith the challenge response are displayed on the merchant computingdevice 150 to the salesperson 102. For example, if ten customers are inthe vicinity of the merchant computing device 150, then the merchantcomputing device 150 may have received ten pending tokens from thepayment processing system 140 associated with the ten customers. Whenthe hands-free payment application 156 on the merchant computing device150 receives the challenge response input, only the potential users thatare associated with the challenge response are displayed to thesalesperson 102.

In another embodiment, the merchant computing device 150 or the paymentprocessing system 140 which processes the challenge, presents additionalchallenges until there is a single matching user 101 remaining.

In the example, if the salesperson 102 inputs “AC” as the initials ofthe user 101 associated with the transaction, then only the potentialusers with those initials will be displayed to the salesperson 102 bythe hands-free payment application 156. The hands-free paymentapplication 156 accesses a database on the merchant computing device150, the payment processing system 140, or another computing device andidentifies the initials of the potential users that have providedtokens. The hands-free payment application 156 identifies the one ormore potential users that have the initials “AC” and displays theidentified user accounts to the salesperson 102. In the example, two ofthe ten customers that are in the vicinity of the merchant computingdevice 150 have the initials “AC.” The user accounts of the twocustomers are displayed to the salesperson 102.

In certain example embodiments, all of the nearby customers who have hadtokens transmitted to the merchant computing device 150 are presented tothe salesperson 102 and the salesperson selects the appropriate useraccount.

The hands-free payment application 156 may display a picture of thepotential user accounts that are presented to the salesperson 102. Forexample, each user 101 may associate a picture with a user account. Whenthe merchant computing device 150 presents the one or more potentialuser accounts to the salesperson 102, the salesperson 102 may select theappropriate user account based on the picture matching the user 101conducting the transaction. Other identifying information may bepresented instead of, or in addition to, a picture. For example, thename of the user may be displayed and the salesperson 102 may identifythe potential user with that name. Any other suitable identifyinginformation may be presented.

In an example embodiment, the picture or other identifying informationmay be transmitted to the merchant computing device 150 as a function ofthe token. In another example, if the picture or other identifyinginformation is not supplied with the token, the identifying informationis requested by the merchant computing device 150 from the paymentprocessing system 140 and received in a communication over the network120. In another example, the identifying information is requested by themerchant computing device 150 from the user computing device 110directly and received in a communication. The identifying informationmay be received from any suitable source.

In block 550, the salesperson 102 selects the user account for thetransaction. After identifying the displayed picture of the user 101,the salesperson 102 may input a selection of the user 101 by actuating auser interface control associated with the picture, or by inputting theselection in any suitable manner. If the picture doesn't match any ofthe potential users, then the salesperson 102 may cancel thetransaction, notify the user 101 of the discrepancy, or perform anyother suitable action.

In an example, only a single user account is presented in the list ofpotential users. If only a single user account is identified, then themethod may proceed after the salesperson 102 verifies that the displayedpicture matches the user 101. If the picture doesn't match, then thesalesperson 102 may cancel the transaction, notify the user 101 of thediscrepancy, or perform any other suitable action.

In block 560, the merchant computing device 150 transmits thetransaction request to the payment processing system 140. Thesalesperson 102 associates the token that is associated with the user101 and the selected user account with the transaction data for theproduct being purchased by the user 101. The salesperson 102 provides anindication on the user interface 155 of the merchant computing device150 that the user 101 has agreed to the purchase transaction. Themerchant computing device 150 transmits the transaction details andtoken associated with the user 101 to payment processing systemhands-free module 141 to conduct the transaction.

From block 560, the method 270 a returns to block 280 of FIG. 2.

FIG. 6 is a block flow diagram depicting a method 270 b for a merchantcomputing device 150 to identify a user 101 and transmit transactionrequest to payment processing system based on voice patterns of the user101, in accordance with certain example embodiments.

In block 610, the salesperson 102 approaches the user location. Thesalesperson 102 may recognize that the user 101 is prepared to make apurchase. The salesperson 102 may proceed to an area in the vicinity ofthe user 101. For example, the salesperson 102 may proceed to an areafrom which the merchant computing device 150 may detect the voice of theuser 101. In another example, the user 101 approaches the area of thesalesperson 102, such as at a POS terminal 134 location.

In block 620, the merchant computing device 150 captures a voice patternof the user 101. In certain embodiments, the user 101 must enable thisfeature in the user account of the payment processing system 140. In theexample, the voice of the user 101 may not be captured or analyzedwithout the permission of the user 101.

In an example, the salesperson 102 may ask the user 101 a question andthe merchant computing device 150 receives the audible response. Inanother example, the merchant computing device 150 may detect the user101 speaking without a request from the salesperson 102. For example,the user 101 may approach the salesperson 102 to request assistance witha purchase, and the merchant computing device 150 detects the request.In another example, the merchant computing device 150 detects the user101 speaking for any other suitable reason.

The merchant computing device 150 stores the voice of the user 101 in astorage device, such as the data storage unit 152, or transmits thevoice of the user 101 to a third party for analysis and storage. Inanother example, the merchant computing device 150 transmits the voiceof the user 101 to the payment processing system 140 to match with users101 that are in the vicinity of the merchant computing device 150.

In block 630, the merchant computing device 150 matches the token to theuser voice pattern. The merchant computing device 150 performs ananalysis of voice of the user 101 and identifies a voice pattern. Themerchant computing device 150 compares the voice pattern of the user 101to a database of voice patterns and identifies the user 101 and theassociated user account. The merchant computing device 150 associatesthe token associated with the user account with the pending transaction.

In an alternate embodiment, the voice pattern of the user 101 isassociated with the token of the user 101 that is transmitted to thepayment processing system hands-free module 141. The voice pattern istransmitted to the merchant computing device along with the token.

In an example, when user 101 is checking out, the user 101 makes astatement, such as “I'd like to pay with the hands-free paymentapplication.” The hands-free payment application 156 on the merchantcomputing device 150 detects the spoken phrase via the microphone orother input of the merchant computing device 150. The spoken phrase isthen compared, on the hands-free payment application 150, with each ofthe stored voice pattern for one or more nearby consumers that havecontributed tokens.

In another example, the user 101 responds to a challenge from thesalesperson 102. For example, the salesperson 102 may ask for theinitials, first name, phone number, or any other response from the 101.In another example, a certain phrase is required from the user 101 toensure a proper voice pattern match. For example, the certain phrase maybe “I'm paying hands-free.”

If a strong match exists for any of the voice patterns, the hands-freepayment application 156 retrieves the user account associated with thematching voice pattern, and retrieves the remaining information aboutthe user 101.

In block 640, the merchant computing device 150 displays the useraccount based on the matching voice pattern. After matching the voicepattern to a user account, the merchant computing device 150 presentsthe user account and any associated information to the salesperson 102via a user interface of the merchant computing device 150. The merchantcomputing device 150 may access user information, a picture of the user101, or other suitable data, from the user account on the paymentprocessing system 140 or any other suitable computing device.

In block 650, the salesperson selects the displayed user account for thetransaction. After verifying the displayed picture of the user 101, orapproving the user account for the transaction in any suitable manner,the salesperson 102 may input a selection of the user 101 by actuating auser interface control associated with the picture, or by inputting theselection in any suitable manner.

In block 660, the merchant computing device 150 transmits thetransaction request to the payment processing system 140. Thesalesperson 102 associates the token that is associated with the user101 and the selected user account with the transaction data for theproduct being purchased by the user 101. The salesperson 102 may providean indication on the user interface 155 of the merchant computing device150 that the user 101 has agreed to the purchase transaction. Themerchant computing device 150 transmits the transaction details andtoken associated with the user 101 to payment processing systemhands-free module 141 to conduct the transaction. In a certainembodiment, the merchant computing device 150 may include the challengeand the challenge response in the transaction request.

From block 660, the method 270 b returns to block 280 of FIG. 2.

In block 280, the payment processing system 140 conducts the transactionand transmits a confirmation to the merchant computing device 150. Thepayment processing system hands-free module 141 receives the transactiondetails and the token from the merchant computing device 150 andprocesses the transaction. The payment processing system hands-freemodule 141 verifies the token as the same token that was previouslyreceived from the user computing device 110 (or generated by the paymentprocessing system hands-free module 141) and provided to the merchantcomputing device 150. If the token is not verified as the same token,then the transaction does not proceed. If the token is not verified, thepayment processing system hands-free module 141 may request the correcttoken from the merchant computing device 150, decline the transaction,alert a payment processing system hands-free module 141 operator, orperform any suitable action to complete or cancel the transaction.

Upon a verification of the token, the payment processing systemhands-free module 141 determines if the user account has the fundsavailable for the transaction. In an example, the payment processingsystem hands-free module 141 may apply the transaction by deducting theamount of the transaction from a pool of funds stored in the useraccount. In another example, the payment processing system hands-freemodule 141 may provide an authorization request to a financial accountissuer, such as a credit or debit card, associated with the account.Upon receiving an authorization from the financial account issuer, thepayment processing system hands-free module 141 proceeds with thetransaction. The user account may be funded by any other suitablesource, such as a bank account, a stored value account, a debit card, orany suitable source. The payment processing system hands-free module 141debits the appropriate account of the user 101 for the amount of thetransaction and credits an account of the merchant for the amount of thetransaction.

The payment processing system hands-free module 141 provides anotification to the merchant system computing device 150 that thetransaction is authorized. The authorization may be presented to thesalesperson 102 by the user interface 155 of the merchant computingdevice 150. Upon receiving the authorization, the salesperson 102 mayprovide the product and a receipt to the user 101 or the user computingdevice 110. Upon settlement of the transaction, the payment processingsystem hands-free module 141 provides the funds for the transaction tothe merchant system 130.

In block 290, upon a successful conducting of the transaction, thepayment processing system 140 transmits a notification of the successfulcompletion of the transaction to the user computing device 110. Thenotification provides the details of the transaction, such as thetransaction amount, the product purchased, and other suitable details.The notification allows the user 101 an opportunity to quickly disputethe charge. For example, the salesperson 102 or the merchant computingdevice 150 may have associated the wrong token with the transactiondetails. In another example, the transaction details were in error andan incorrect amount was deducted from the user account. The user 101receives the notification on the user computing device 110 and views thetransaction details on the user interface 115. In an alternate example,the user 101 receives the notification from the payment processingsystem 140 as an email, a text, as a notification on the hands-freepayment application, or in any suitable manner. In an alternateembodiment, the notification may be provided by the merchant computingdevice 150. For example, the merchant computing device 150 provides atext to the user computing device with the transaction details.

The notifications, receipts, and other transaction data may be stored ina list on a database or other storage system on the user computingdevice 110, the hands-free payment application 116, or any suitablestorage location. The notifications, receipts, and other transactiondata may be stored in a list on a user account or other location on thepayment processing system 140. The user 101 may access the list toreview recent transactions, to seek refunds, or for any suitable reason.In certain examples, the list on the user computing device 110 maysynchronize with the list on the payment processing system 140 eitherautomatically or when prompted by the user 101.

FIG. 7 is a block flow diagram depicting a method 700 for a hands-freetransaction with a confirmation, in accordance with certain exampleembodiments. The method 700 is described with reference to thecomponents illustrated in FIG. 1.

Block 210 through block 270 are substantially similar to the blocks 210through 270 described previously with regard to FIG. 2. In FIG. 7, themethod 700 proceeds from block 270 to block 775.

In block 775, the payment processing system 140 requests confirmation ofthe transaction from user computing device 110. Block 775 is describedin more detail hereinafter with reference to the method 775 described inFIG. 8.

FIG. 8 is a block diagram depicting a method 775 for a paymentprocessing system 140 to request confirmation of a transaction from theuser computing device 110. The method 775 is described with reference tothe components illustrated in FIG. 1.

In block 810, the payment processing system hands-free module 141receives the transaction request and the token from the merchantcomputing device 150. The transaction request comprises the transactionamount in addition to other relevant transaction data.

In block 820, the payment processing system hands-free module 141determines that the transaction amount is greater than a configuredlimit on the user account. For example, from the information in thetoken and the transaction data, the payment processing system hands-freemodule 141 identifies the user account associated with the transaction.The payment processing system hands-free module 141 compares thetransaction amount to any configured transaction amount limit in theuser account. In an example, the limit may be $10, $50, or $100. Anysuitable limit may be configured.

The amount of the transaction limit may be configured by the user 101,the payment processing system hands-free module 141, a financial accountissuer associated with the user account, or any suitable party. Forexample, the user 101 may configure a transaction limit during theaccount setup to protect against a fraudulent transaction. In anotherexample, a financial account issuer associated with the user account maycommunicate a hands-free transaction limit to the payment processingsystem hands-free module 141 based on the credit history of the user 101or based any suitable qualifications. In certain embodiments, thetransaction limit is obtained by the payment processing systemhands-free module 141 from data in the token.

If the transaction amount is greater than the configured limit, then thepayment processing system hands-free module 141 recognizes that thetransaction requires additional authorization. In certain exampleembodiments, the user account may be configured to require that alltransactions may require an authorization. Any other requirement for atransaction may be placed on the user account. For example, the user 101may configure the account to specify that all transactions with aparticular merchant system 130, or a group of merchant systems, requireuser authorization. In another example, the user 101 may configure theaccount to specify that all transactions for certain products requireuser authorization.

In block 830, the payment processing system hands-free module 141transmits a request for authorization of the transaction to the usercomputing device 110. The request may be transmitted via the Internet tothe hands-free payment application 116, transmitted via email or text,or transmitted in any suitable manner. The request for authorization maycomprise transaction details sufficient to allow the user 101 toidentify the transaction needing approval. The request may include theidentity of the merchant system 130, a description of the product beingpurchased, an identification number of the product, an amount of fundsrequired to conduct the transaction, a geographic location of themerchant system 130, or any other suitable data.

In block 840, the user computing device 110 receives an input of aconfirmation from the user 101. Along with a presentation of thetransaction data, the hands-free payment application 116, or otherapplication employing a user interface 115, displays a request to theuser 101 for an authorization of the transaction. The display mayprovide a control, or other selectable option for the user 101 to inputan option to authorize the transaction or refuse the transaction. If theuser 101 authorizes the transaction, the user 101 inputs the selectioninto the user interface 115 by selecting the appropriate button or othercontrol. In alternate embodiments, the user authorization may be inputvia a voice control, a swipe or other motion with the user computingdevice 110, or via any other suitable action of the user 101.

If the user 101 does not authorize a request, then the method may end orthe user computing device 110 may transmit the refusal of thetransaction to the payment processing system hands-free module 141. Ifauthorized by the user 101, the user computing device transmits theauthorization to the payment processing system 140.

In block 850, upon receiving the authorization of the transaction fromthe user 101, the user computing device 110 generates a second token.The second token is generated in a similar manner as the generation ofthe first token as described in block 230 of FIG. 2. In addition to thepreviously described data associated with the token, the second tokencomprises the authorization of the transaction as received from theinput of the user 101. In an alternate embodiment, a second token is notcreated. In an example, the authorization is provided to the paymentprocessing system via a communication over the network 120.

In block 860, the payment processing system hands-free module 141receives the second token and applies the second token to the pendingtransaction. The payment processing system hands-free module 141discards the original token received from the merchant computing device150 and applies the second token to the transaction. The paymentprocessing system hands-free module 141 recognizes the authorizationfrom the user 101 in the token and overrides the limit on the useraccount. The payment processing system hands-free module 141 may beconfigured not to proceed with a token that does not meet thetransaction criteria. A second token that is not bound by a transactionlimit lower than the transaction amount may be required.

In an alternate example, the payment processing system hands-free module141 does not receive the second token to apply to the pendingtransaction. The user computing device 110 provides an authorizationfrom the user 101 to conduct the transaction and override thetransaction limit. The payment processing system hands-free module 141overrides the transaction limit in the user account and uses the firsttoken for any further processing of the transaction.

From block 860, the method 775 returns to block 280 of FIG. 7.

Block 280 and block 290 are substantially similar to the blocks 280 and290 with respect to FIG. 2. The token used to conduct the transaction inthe embodiment of FIG. 7 is the second generated token. In certainalternate embodiments, upon receiving the confirmation from the usercomputing device 110 for the transaction, the payment processing system140 accesses the original token and utilizes the original token for thetransaction. In an example, the payment processing system 140 overridesthe transaction limit of the original token based on the authorizationof the user 101 and conducts the transaction with the original token.

In certain example embodiments, the payment processing system 140 willoffer incentives to users 101 to utilize the hands-free payment process.Incentives may be offered to the merchant system 130, the salesperson102, and/or the user 101.

The incentives may be structured in two groups. The first group is“ongoing earnings.” In an example, an ongoing earning type of incentivesystem is a percentage cash back. In another example, the incentive is apoints based loyalty system.

Another group of incentives is “surprise incentives.” Surpriseincentives are not predictable, nor are surprise incentives the samevalue every time and they can have an amplifying effect atreinvigorating and delighting a user 101. Surprise promotions serve thesame purpose. An algorithm on the payment processing system hands-freemodule 141 may have a rules engine for handing out gifts, discounts orpromotions based on usage patterns of the user 101 as well as overallhealth of the network.

Users 101 may not know when a gift or discount is available. The users101 find out that the payment processing system 140 just picked up thetab after the transaction happens. This creates a delight factor. Thesystem can also be set up to reward repeat/loyal users 101 moreaggressively.

In an example, the payment processing system hands-free module 141 maymonitor the transaction history of the user account and provide asurprise incentive after a configured number of transactions. Forexample, the third transaction may be funded by the payment processingsystem 140 and the user account is not charged. In an example, the thirdtransaction is only billed if the total is under a configured amount. Incertain example embodiments the transaction that is funded by thepayment processing system 140 is selected based on a random selection.For example, an algorithm may be utilized that randomly selects atransaction for funding by the payment processing system 140. In anotherexample, the transaction that is funded by the payment processing system140 is selected is based on an algorithm that analyzes the transactionhistory of the user 101 and configures the selection in an appropriatemanner. In a certain example embodiment, the payment processing systemhands-free module 141 may be configured to offer a user account a 1 in10 chance of having a pending transaction funded by the paymentprocessing system 140. Any odds of winning or other selection criteriamay be utilized.

In another example, the transaction is not fully funded, but isdiscounted by a configured percentage. For example, an algorithm may beutilized that randomly selects a percentage that will be funded by thepayment processing system 140.

A level of unpredictability in the surprise rewards or discountsencourages users 101 to more frequently utilize the hands-free payments.Unlike cash back rewards, where users 101 can get complacent over time,users 101 will keep using hands-free payments in the hope of gettingrewarded again.

In another example, the percentage that will be funded by the paymentprocessing system 140 is selected is based on an algorithm that analyzesthe transaction history of the user 101 and configures the selection inan appropriate manner. Any suitable surprise discount or reward to theuser account may be utilized.

In certain example embodiments, the payment processing system 140 mayprovide surprise rewards to a user account based on the number oftransactions conducted. For example, when an user account has a greaternumber of conducted transactions, the amount or the frequency of therewards or discounts is increased.

Consumer incentive design parameters gets users 101 over an initial humpand promotes active sign ups. Consumer incentives encourage repeatedbehavior and build long-term loyalty to the payment processing system140. Consumer incentives grow stored value and encourage users 101 tolink their bank account and maintain a user account with fundsavailable. Consumer incentives build brand awareness so users 101 thinkhands-free payments is innovative and want to use it everywhere.

Merchant incentive design parameters contribute to customer loyalty,bring in foot traffic for both new and existing customers, and reducecosts.

Salesperson 102 incentive design parameters cause the salesperson toencourage customers to try hands-free payments and push merchant systemsto adopt hands-free payments. Customer service is also improved whileusing hands-free payments. In an example embodiment, the salesperson 102may receive a certain percentage, such as 10%, of hands-free orders. Thepayment processing system 140 may register the salesperson 102 thatconducted the hands-free payment transaction based on detailstransmitted with the transaction details and provide a payment to thesalesperson 102 in the form of a check.

Other Example Embodiments

FIG. 9 depicts a computing machine 2000 and a module 2050 in accordancewith certain example embodiments. The computing machine 2000 maycorrespond to any of the various computers, servers, mobile devices,embedded systems, or computing systems presented herein. The module 2050may comprise one or more hardware or software elements configured tofacilitate the computing machine 2000 in performing the various methodsand processing functions presented herein. The computing machine 2000may include various internal or attached components such as a processor2010, system bus 2020, system memory 2030, storage media 2040,input/output interface 2060, and a network interface 2070 forcommunicating with a network 2080.

The computing machine 2000 may be implemented as a conventional computersystem, an embedded controller, a laptop, a server, a mobile device, asmartphone, a set-top box, a kiosk, a vehicular information system, onemore processors associated with a television, a customized machine, anyother hardware platform, or any combination or multiplicity thereof. Thecomputing machine 2000 may be a distributed system configured tofunction using multiple computing machines interconnected via a datanetwork or bus system.

The processor 2010 may be configured to execute code or instructions toperform the operations and functionality described herein, managerequest flow and address mappings, and to perform calculations andgenerate commands. The processor 2010 may be configured to monitor andcontrol the operation of the components in the computing machine 2000.The processor 2010 may be a general purpose processor, a processor core,a multiprocessor, a reconfigurable processor, a microcontroller, adigital signal processor (“DSP”), an application specific integratedcircuit (“ASIC”), a graphics processing unit (“GPU”), a fieldprogrammable gate array (“FPGA”), a programmable logic device (“PLD”), acontroller, a state machine, gated logic, discrete hardware components,any other processing unit, or any combination or multiplicity thereof.The processor 2010 may be a single processing unit, multiple processingunits, a single processing core, multiple processing cores, specialpurpose processing cores, co-processors, or any combination thereof.According to certain example embodiments, the processor 2010 along withother components of the computing machine 2000 may be a virtualizedcomputing machine executing within one or more other computing machines.

The system memory 2030 may include non-volatile memories such asread-only memory (“ROM”), programmable read-only memory (“PROM”),erasable programmable read-only memory (“EPROM”), flash memory, or anyother device capable of storing program instructions or data with orwithout applied power. The system memory 2030 may also include volatilememories such as random access memory (“RAM”), static random accessmemory (“SRAM”), dynamic random access memory (“DRAM”), and synchronousdynamic random access memory (“SDRAM”). Other types of RAM also may beused to implement the system memory 2030. The system memory 2030 may beimplemented using a single memory module or multiple memory modules.While the system memory 2030 is depicted as being part of the computingmachine 2000, one skilled in the art will recognize that the systemmemory 2030 may be separate from the computing machine 2000 withoutdeparting from the scope of the subject technology. It should also beappreciated that the system memory 2030 may include, or operate inconjunction with, a non-volatile storage device such as the storagemedia 2040.

The storage media 2040 may include a hard disk, a floppy disk, a compactdisc read only memory (“CD-ROM”), a digital versatile disc (“DVD”), aBlu-ray disc, a magnetic tape, a flash memory, other non-volatile memorydevice, a solid state drive (“SSD”), any magnetic storage device, anyoptical storage device, any electrical storage device, any semiconductorstorage device, any physical-based storage device, any other datastorage device, or any combination or multiplicity thereof. The storagemedia 2040 may store one or more operating systems, application programsand program modules such as module 2050, data, or any other information.The storage media 2040 may be part of, or connected to, the computingmachine 2000. The storage media 2040 may also be part of one or moreother computing machines that are in communication with the computingmachine 2000 such as servers, database servers, cloud storage, networkattached storage, and so forth.

The module 2050 may comprise one or more hardware or software elementsconfigured to facilitate the computing machine 2000 with performing thevarious methods and processing functions presented herein. The module2050 may include one or more sequences of instructions stored assoftware or firmware in association with the system memory 2030, thestorage media 2040, or both. The storage media 2040 may thereforerepresent examples of machine or computer readable media on whichinstructions or code may be stored for execution by the processor 2010.Machine or computer readable media may generally refer to any medium ormedia used to provide instructions to the processor 2010. Such machineor computer readable media associated with the module 2050 may comprisea computer software product. It should be appreciated that a computersoftware product comprising the module 2050 may also be associated withone or more processes or methods for delivering the module 2050 to thecomputing machine 2000 via the network 2080, any signal-bearing medium,or any other communication or delivery technology. The module 2050 mayalso comprise hardware circuits or information for configuring hardwarecircuits such as microcode or configuration information for an FPGA orother PLD.

The input/output (“I/O”) interface 2060 may be configured to couple toone or more external devices, to receive data from the one or moreexternal devices, and to send data to the one or more external devices.Such external devices along with the various internal devices may alsobe known as peripheral devices. The I/O interface 2060 may include bothelectrical and physical connections for operably coupling the variousperipheral devices to the computing machine 2000 or the processor 2010.The I/O interface 2060 may be configured to communicate data, addresses,and control signals between the peripheral devices, the computingmachine 2000, or the processor 2010. The I/O interface 2060 may beconfigured to implement any standard interface, such as small computersystem interface (“SCSI”), serial-attached SCSI (“SAS”), fiber channel,peripheral component interconnect (“PCI”), PCI express (PCIe), serialbus, parallel bus, advanced technology attached (“ATA”), serial ATA(“SATA”), universal serial bus (“USB”), Thunderbolt, FireWire, variousvideo buses, and the like. The I/O interface 2060 may be configured toimplement only one interface or bus technology. Alternatively, the I/Ointerface 2060 may be configured to implement multiple interfaces or bustechnologies. The I/O interface 2060 may be configured as part of, allof, or to operate in conjunction with, the system bus 2020. The I/Ointerface 2060 may include one or more buffers for bufferingtransmissions between one or more external devices, internal devices,the computing machine 2000, or the processor 2010.

The I/O interface 2060 may couple the computing machine 2000 to variousinput devices including mice, touch-screens, scanners, electronicdigitizers, sensors, receivers, touchpads, trackballs, cameras,microphones, keyboards, any other pointing devices, or any combinationsthereof. The I/O interface 2060 may couple the computing machine 2000 tovarious output devices including video displays, speakers, printers,projectors, tactile feedback devices, automation control, roboticcomponents, actuators, motors, fans, solenoids, valves, pumps,transmitters, signal emitters, lights, and so forth.

The computing machine 2000 may operate in a networked environment usinglogical connections through the network interface 2070 to one or moreother systems or computing machines across the network 2080. The network2080 may include wide area networks (WAN), local area networks (LAN),intranets, the Internet, wireless access networks, wired networks,mobile networks, telephone networks, optical networks, or combinationsthereof. The network 2080 may be packet switched, circuit switched, ofany topology, and may use any communication protocol. Communicationlinks within the network 2080 may involve various digital or an analogcommunication media such as fiber optic cables, free-space optics,waveguides, electrical conductors, wireless links, antennas,radio-frequency communications, and so forth.

The processor 2010 may be connected to the other elements of thecomputing machine 2000 or the various peripherals discussed hereinthrough the system bus 2020. It should be appreciated that the systembus 2020 may be within the processor 2010, outside the processor 2010,or both. According to some embodiments, any of the processor 2010, theother elements of the computing machine 2000, or the various peripheralsdiscussed herein may be integrated into a single device such as a systemon chip (“SOC”), system on package (“SOP”), or ASIC device.

In situations in which the systems discussed here collect personalinformation about users, or may make use of personal information, theusers may be provided with an opportunity or option to control whetherprograms or features collect user information (e.g., information about auser's social network, social actions or activities, profession, auser's preferences, or a user's current location), or to control whetherand/or how to receive content from the content server that may be morerelevant to the user. In addition, certain data may be treated in one ormore ways before it is stored or used, so that personally identifiableinformation is removed. For example, a user's identity may be treated sothat no personally identifiable information can be determined for theuser, or a user's geographic location may be generalized where locationinformation is obtained (such as to a city, ZIP code, or state level),so that a particular location of a user cannot be determined. Thus, theuser may have control over how information is collected about the userand used by a content server.

Embodiments may comprise a computer program that embodies the functionsdescribed and illustrated herein, wherein the computer program isimplemented in a computer system that comprises instructions stored in amachine-readable medium and a processor that executes the instructions.However, it should be apparent that there could be many different waysof implementing embodiments in computer programming, and the embodimentsshould not be construed as limited to any one set of computer programinstructions. Further, a skilled programmer would be able to write sucha computer program to implement an embodiment of the disclosedembodiments based on the appended flow charts and associated descriptionin the application text. Therefore, disclosure of a particular set ofprogram code instructions is not considered necessary for an adequateunderstanding of how to make and use embodiments. Further, those skilledin the art will appreciate that one or more aspects of embodimentsdescribed herein may be performed by hardware, software, or acombination thereof, as may be embodied in one or more computingsystems. Moreover, any reference to an act being performed by a computershould not be construed as being performed by a single computer as morethan one computer may perform the act.

The example embodiments described herein can be used with computerhardware and software that perform the methods and processing functionsdescribed herein. The systems, methods, and procedures described hereincan be embodied in a programmable computer, computer-executablesoftware, or digital circuitry. The software can be stored oncomputer-readable media. For example, computer-readable media caninclude a floppy disk, RAM, ROM, hard disk, removable media, flashmemory, memory stick, optical media, magneto-optical media, CD-ROM, etc.Digital circuitry can include integrated circuits, gate arrays, buildingblock logic, field programmable gate arrays (FPGA), etc.

The example systems, methods, and acts described in the embodimentspresented previously are illustrative, and, in alternative embodiments,certain acts can be performed in a different order, in parallel with oneanother, omitted entirely, and/or combined between different exampleembodiments, and/or certain additional acts can be performed, withoutdeparting from the scope and spirit of various embodiments. Accordingly,such alternative embodiments are included in the scope of the followingclaims, which are to be accorded the broadest interpretation so as toencompass such alternate embodiments.

Although specific embodiments have been described above in detail, thedescription is merely for purposes of illustration. It should beappreciated, therefore, that many aspects described above are notintended as required or essential elements unless explicitly statedotherwise. Modifications of, and equivalent components or actscorresponding to, the disclosed aspects of the example embodiments, inaddition to those described above, can be made by a person of ordinaryskill in the art, having the benefit of the present disclosure, withoutdeparting from the spirit and scope of embodiments defined in thefollowing claims, the scope of which is to be accorded the broadestinterpretation so as to encompass such modifications and equivalentstructures.

What is claimed is:
 1. A computer-implemented method for hands-freetransactions, comprising: receiving, by the one or more computingdevices, a communication from a user computing device, the communicationcomprising a first transaction token, an identification of a useraccount, and a beacon identifier received by the user computing devicefrom a merchant device associated with a merchant computing system, thetoken having been created by the user computing device in response tothe user computing device receiving the beacon identifier from themerchant device; communicating, by the one or more computing devices,the first transaction token to the merchant computing system associatedwith the beacon identifier; receiving, by the one or more computingdevices and from the merchant computing system, a transaction request,the transaction request comprising the first transaction token andtransaction data associated with the transaction request, the firsttransaction token having been associated with the transaction data bythe merchant computing system; determining, by the one or more computingdevices, based on the transaction data that the transaction is for anamount greater than a configured transaction limit for hands-freetransactions associated with the user account; communicating, by the oneor more computing devices and to the user computing device, a requestfor an authorization of the transaction in response to determining thatthe transaction is for an amount greater than the configured transactionlimit for hands-free transactions associated with the user account;receiving, by the one or more computing devices and from the usercomputing device, the authorization of the transaction, theauthorization comprising a second transaction token; and conducting, bythe one or more computing devices, the transaction between the useraccount and the merchant system in response to receiving theauthorization and based on the second transaction token.
 2. Thecomputer-implemented method of claim 1, further comprising determining,by the one or more computing devices, that the configured transactionlimit indicates that all requests for hands-free transactions associatedwith the user account to require user authorization.
 3. Thecomputer-implemented method of claim 1, wherein user authorization ofthe transaction is received by the user computing device from an inputof the user.
 4. The computer-implemented method of claim 1, wherein thetransaction limit for hands-free transactions associated with the useraccount is configured by one or more of the user or the one or morecomputing devices.
 5. The computer-implemented method of claim 1,wherein the transaction limit for hands-free transactions associatedwith the user account is configured by a financial account issuerassociated with the user account.
 6. The computer-implemented method ofclaim 1, wherein the first and the second transaction tokens provide anauthorization for the one or more computing devices to conduct atransaction with the user account within a scope provided by each of thefirst and the second transaction tokens.
 7. The computer-implementedmethod of claim 1, wherein the request for the authorization of thetransaction is communicated upon a determination that the transactionrequest is received from the merchant system computing device associatedwith a particular merchant.
 8. A computer program product, comprising: anon-transitory computer-readable storage device having computer-readableprogram instructions embodied thereon that when executed by a computercause the computer to conduct hands-free transactions, thecomputer-readable program instructions comprising: computer-readableprogram instructions to receive a communication from a user computingdevice, the communication comprising a first transaction token, anidentification of a user account, and a beacon identifier received bythe user computing device from a merchant device associated with amerchant computing system, the token having been created by the usercomputing device in response to the user computing device receiving thebeacon identifier from the merchant device; computer-readable programinstructions to receive from the merchant computing system, atransaction request, the transaction request comprising the firsttransaction token and transaction data associated with the transactionrequest, the first transaction token having been received by themerchant computing system from the user computing device, and the firsttransaction token having been associated with the transaction data bythe merchant computing system; computer-readable program instructions todetermine based on the transaction data that the transaction is for anamount greater than a configured transaction limit for hands-freetransactions associated with the user account; computer-readable programinstructions to communicate to the user computing device, a request foran authorization of the transaction in response to determining that thetransaction is for an amount greater than the configured transactionlimit for hands-free transactions associated with the user account;computer-readable program instructions to receive from the usercomputing device, the authorization of the transaction; andcomputer-readable program instructions to conduct the transactionbetween the user account and the merchant system in response toreceiving the authorization.
 9. The computer program product of claim 8,wherein the authorization of the transaction comprises a secondtransaction token from the user computing device, and wherein thetransaction is conducted based on the second token.
 10. The computerprogram product of claim 9, wherein the first and the second transactiontokens provide an authorization to the one or more computing devices toconduct a transaction with the user account within a scope provided bythe first and the second transaction tokens.
 11. The computer programproduct of claim 8, wherein the transaction is conducted based on thefirst token.
 12. The computer program product of claim 8, wherein theconfigured transaction limit indicates that all requests for hands-freetransactions associated with the user account require userauthorization.
 13. The computer program product of claim 8, wherein userauthorization of the transaction is received by the user computingdevice from an input of the user.
 14. The computer program product ofclaim 8, wherein the request for the authorization of the transaction iscommunicated upon a determination that the transaction request isreceived from the merchant system computing device associated with aparticular merchant.
 15. A system for hands-free transactions,comprising: a storage device; and a processor communicatively coupled tothe storage device, wherein the processor executes application codeinstructions that are stored in the storage device to cause the systemto: receive a communication from a hands-free payment application on auser computing device, the communication comprising a first transactiontoken; receive from a merchant computing system, a transaction request,the transaction request comprising the first transaction token andtransaction data associated with the transaction request; determinebased on the received transaction data that the transaction is for anamount greater that a configured transaction limit for hands-freetransactions associated with a user account associated with the firsttransaction token; communicate to the user computing device a requestfor an authorization of the transaction in response to determining thatthe transaction is for an amount greater that a configured transactionlimit for hands-free transactions associated with a user accountassociated with the first transaction token; receive from the usercomputing device the authorization of the transaction; and conduct thetransaction between the user account and the merchant computing systemin response to receiving the authorization of the transaction.
 16. Thesystem of claim 15, wherein the authorization of the transactioncomprises a second transaction token from the user computing device, andwherein the transaction is conducted based on the second token.
 17. Thesystem of claim 15, wherein the transaction is conducted based on thefirst token.
 18. The system of claim 15, wherein the configuredtransaction limit indicates that all requests for hands-freetransactions associated with the user account require userauthorization.
 19. The system of claim 15, wherein the transaction limitfor hands-free transactions associated with the user account isconfigured by one or more of the user or the one or more computingdevices.
 20. The system of claim 15, wherein the request for theauthorization of the transaction is communicated upon a determinationthat the transaction request is received from the merchant systemcomputing device associated with a particular merchant.